Increasingly, enterprises are looking for ways to simplify access and organization of Information Technology (IT) services. One mechanism for providing such IT simplification is Service Oriented Architecture (SOA). Application of SOA principles promises faster development cycles, increased reusability and better change tolerance for software components.
Unfortunately, enterprises that implement SOA often find that the start-up complexities of SOA delays, if not derails, the expected return on investment. While SOA simplifies the complexity of an IT environment, organizations lack sufficient experience with SOA technology required for a quick, trouble-free implementation. Compounding this experience gap, graphical tools for implementing SOA are not readily available, so that data services for use in SOA environments often must be hand-coded. For enterprise-class portal and Web applications, for example, a majority of application development time can be spent on managing data access. A number of factors make data programming difficult and time-consuming, including data access control. Accordingly, there exists a continued need for improved mechanisms for security data redaction in implementing SOA type initiatives.
One problem that arises is controlling access to data by different individuals. One conventional approach includes controlling individual's access to data storage constructs, i.e., files, databases and so forth, using a scheme of access permissions. For example, a user may be granted some combination of read, write, modify and delete authority for a particular file, database or other data storage construct. Such conventional approaches, however, require the user to be cleared for the entire content of the data storage construct.
Another conventional approach includes controlling access to the services by individuals. A problem with such approaches, however, arises from the coarseness of the approaches' granularity—an individual is either permitted to use the service or denied access to the service. Some implementations have sought to ameliorate this drawback by establishing classes of access, i.e., user, administrator and so forth, each class having access to a specific set of functions in the service. Each of these conventional approaches, however, suffers the same limitation—an individual granted access to the service, or the data storage construct, has access to the entirety of the data.